This invention relates to electronic programmable controllers for operating industrial equipment, and more particularly, to an editor used to develop control programs performed by industrial controllers to control industrial equipment.
Programmable controllers are well-known systems for operating industrial equipment, such as assembly lines and machine tools, in accordance with a stored program. In these controllers, a stored program is executed to examine the condition of specific sensing devices on the controlled equipment, and to energize or deenergize selected operating devices on that equipment contingent upon the status of one or more of the examined sensing devices. The program not only manipulates single-bit input and output data representing the state of the sensing and operating devices, but also performs arithmetic operations, timing and accounting functions, and more complex processing operations.
One industry which extensively uses programmable controllers is the automotive industry. In the automotive industry, various automotive parts are conveyed along machine lines consisting of many consecutive workstations, most workstations including at least one tool which performs some function to alter the characteristics of workpieces as they are delivered to the station. For example, an unfinished cast engine block that requires a plurality of holes, bores, and threads, as well as other metal-removing procedures, may be provided at the beginning of a machine line that produces finished engine blocks. The machine line may consist of any number of different stations, each station performing a different procedure on the unfinished block. An indexer in the form of a transfer bar can be arranged to move each block from one station to the next following a completed process. Typically, at each station the block would be clamped prior to any metal-removing operation.
In this type of a system, a programmable controller would receive inputs from all of the various tools at all of the workstations and would provide activating output signals to synchronize machine operation. During metal-removing periods with the transfer bar out of the way, all of the tools would perform their functions. In between metal-removing periods during transfer periods, the tools would be parked, the clamps unclamped, and the transfer bar would advance workpieces from one station to the next.
Industrial controllers are frequently programmed in "relay ladder" language (RLL) where instructions are represented graphically by "contacts" and "coils" of virtual relays connected and arranged in ladder-like rungs across power and ground rails. RLL, with its input contacts and output coils, reflects the emphasis in industrial control on the processing of large amounts of input and output data.
RLL also reflects the fact that most industrial control is "real time"; that is, an ideal industrial controller behaves as if it were actually composed of multiple relays connected in parallel rungs to provide outputs in essentially instantaneous response to changing inputs. Present industrial controllers do not, in fact, employ separate parallel relay-like structures, but instead simulate the parallel operation of the relays by means of a conventional Von Neumann-type computer processor which executes instructions one at a time, sequentially. The practical appearance of parallel operation is obtained by employing extremely fast processors in the execution of the sequential control program.
As each rung is executed, inputs represented by the contacts are read from memory (as obtained from inputs from the controlled process or the previous evaluation of coils of other rungs). These inputs are evaluated according to the logic reflected in the connection of the contacts into one or more branches within the rungs. Contacts in series across a rung represent boolean AND logic whereas contacts in different branches and thus in parallel across the rung represent boolean OR logic.
Typically a single output coil at the end of each rung is set or reset and, based on the evaluation of that rung, this setting or resetting is reflected in the writing to memory of a bit (which ultimately becomes an output to the industrial process or to another RLL rung).
Once a given rung is evaluated, the next rung is evaluated and so forth. In the simplest form of RLL programming, there are no jumps, i.e. all rungs are evaluated in a cycle or "scan" through the rungs. This is in contrast to conventional computer programming, where branch and jump instructions cause later instructions or groups of instructions to be skipped, depending on the outcome of a test associated with those branch or jump instructions.
While RLL is well-suited for controlling industrial processes like those in the automotive industry, RLL programming is not an intuitive process and, therefore, requires highly-skilled programmers. Where hundreds of machine tool movements must be precisely synchronized to provide a machining process, programming in RLL is extremely time-consuming. The time and relative skill associated with RLL programming together account for an appreciable percentage of overall costs associated with a control system. In addition, the final step in RLL programming is typically a lengthy debugging and reworking step which further adds to overall system costs.
One way to streamline any type of programming is to provide predefined language modules which can be used repetitively each time a specific function is required. Because of the similar types of tools and movements associated with different machine-line stations, industrial control would appear to be an ideal industry for such language modules.
For example, various stations in a single machine line could employ drilling tools having identical limiting motion and configuration parameters.
In this case the idea would be to design a ladder-logic language module for a drill once, place the drill language module into a control library and thereafter, each time drill logic is required, download the drill language module into a control program. Similarly, language modules for other types of tools could be designed once and then used repetitively to reduce programming and debugging time. The module library could be expanded until virtually all tool movements were represented. Library components would be viewed as "black boxes" with predefined interfaces, in much the same way that integrated circuits are used in the electronics industry.
In addition to making it easier to program RLL, a comprehensive module library would also facilitate automated RLL programming using automatic programming apparati. For example, an electronic programming apparatus could provide means whereby a user could construct a machine image including all tools and required movements. The apparatus could then glean machine information from the image and provide required modules for machine control.
The module library approach would work quite well for certain applications like small parts-material handling or simple machining. The reason for this is that the RLL logic required for these applications tends be very small and highly reusable because the I/O count is minimal.
Unfortunately, it is extremely difficult to provide a comprehensive module library for all industrial applications because most applications have a large and varying job specific I/O count. One particularly difficult yet common application to provide RRL logic for is a machine linear axis. The term linear axis will be used hereinafter to refer to an assembly of two or more mechanical components wherein one component has freedom to move with respect to the other in a reciprocal manner along a single axis between two end points. For example, a drill slide is a linear axis. In this example an ideal drill is mounted on a carriage that rides along a rail between two separate limiting positions on the linear axis, an advanced position and a returned position. Two limit switches, referred to herein as returned and advanced LSs, are positioned below the carriage and, when tripped, signal that the drill is in the returned and advanced positions, respectively. Two separate dogs (i.e. trigger extensions), an advanced dog and a returned dog, extend downwardly from the bottom of the carriage to trip the LSs when the advanced and returned positions are reached, respectively. In the ideal case, both LSs may be assumed to be wired in the same "normally opened" manner, so that electrically speaking they are open when released and closed when triggered. In this ideal case, where the physical characteristics of the switches are limited, a single RLL logic rung can determine when the drill is in the returned position and another rung can determine when the drill is in the advanced position.
There are electrically two types of LSs, one LS type being wired normally opened and the other type wired normally closed. Any LS can be mechanically installed in a tripped-when-activated configuration, or released-when-activated configuration. All combinations of these types are used for various types of applications. Thus, application requirements may demand control logic capable of handling any configuration of LS types.
Simple mathematics demonstrates that with two different electrical types of LSs and two mechanical configurations, there are sixteen possible configurations of a two-switch linear slide. Consider the language modules required to implement position logic for all these configurations. To accommodate all sixteen switch configurations, there could be sixteen different language modules, each containing fixed RLL logic, and each named for the case it could handle. In this case, there would be duplicate logic under different names. Alternatively, four unique language modules could be provided, but then the user would have difficulty identifying which of the sixteen physical configurations could be handled by which of the four modules.
Clearly, even for a simple drill mounted for movement along a two position linear axis, application variables make it difficult to provide a workable library of fixed language modules. Adding more switches to the linear slide only increases, to an unmanageable level, the number of language modules required in the library.
Moreover, the contents of a complete language module of a drill must also consider other variables including the number and type of actuators required; the type of spindle, if any, whether or not a bushing plate is required, what type of conveyor is used, whether or not the drill will include an operator panel to enable local control, and, if an operator panel is included, what type of controls (i.e. buttons, switches and indicator lights) are required, just to name a few. Each tool variable increases the required number of unique RLL modules by more than a factor of two, which makes it difficult at best to provide an RLL library module for each possible drill configuration.
For this reason, while attempts have been made to provide reusable RLL logic modules and to provide automated RLL programming apparati, none have proven extremely successful and RLL programming for linear axes is done from scratch.
Some industrial machines have defined states with specific events indicating when a transition should occur from one state to another. In these cases, a different programming language called state sequencing can be used to provide control where a sequencer type controller is provided. Exemplary sequencer type controllers are described in U.S. Pat. Nos. 3,974,484 and 5,042,002.
U.S. Pat. No. 5,321,603 describes one programming apparatus that includes a graphical behavior profile editor that facilitates programming in a state sequencing language. A user can use the apparatus to construct a behavior profile for a machine linear axis. The apparatus gleans information from the behavior profile and provides a state sequence program to control the axis. While this apparatus works quite well to provide state sequence programs, state sequence programs cannot be performed by RLL controllers.
Whereas most control engineers are familiar with ladder diagrams and other graphical representations of machine operation, they are not accustomed to defining operation in terms of state diagrams for a sequencer controller. For this reason, most controllers are of the RLL type instead of the state sequencing type and therefore linear axis programming is not an automated procedure.
Therefore, in order to reduce programming time and associated costs, it would be advantageous to have a more flexible means of specifying control logic that provides for the specification of reusable sections of RLL coded logic for controlling a linear machine axis. In addition, it would be advantageous if such a means enabled less-skilled programmers to provide RLL logic required to control an axis. Moreover, it would be advantageous if a set or library of reusable logic could be accessed using a programming apparatus such as a personal computer, or the like, to further minimize programming time required to program machine axis movements.